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SYSTEM FOR ROUTING AND SWITCHING 
IN COMPUTER NETWORKS 

STATEMENT OF GOVERNMENT LICENSE 
RIGHTS 

The United States Government has a paid-up license in 
portions of this invention and the right in limited circum- 
stances to require the patent owner to license others on 
reasonable terms as provided for by the terms of Contract 
No.: DAAH01-98-C-R005, awarded by the U.S. Army Avia- 
tion & Missile Command. 

FIELD OF THE INVENTION 

The present invention relates to routing and switching 
protocols in computer networks, e.g., ad hoc networks, and 
may find particular application in such networks that utilize 
radio communication links and in which routers can have 
both hosts and networks attached to them. 

BACKGROUND 

Multi-hop packet-radio networks, or ad hoc networks, 
consist of mobile hosts interconnected by routers that can 
also move. The deployment of such routers is ad hoc and the 
topology of such networks is very dynamic, because of host 
and router mobility, signal loss and interference, and power 
outages. In addition, the channel bandwidth available in ad 
hoc networks is relatively limited compared to wired 
networks, and untethered routers may need to operate with 
battery-life constraints. In these networks, routing must 
preferably be accomplished using as few a number of 
control messages and neighbor-to-neighbor handshakes as 
possible, in order to conserve channel bandwidth for user 
data and preserve the battery life of untethered nodes. 
Because of the dynamics of the topology in an ad hoc 
network, broadcast radio links are preferable for intercon- 
necting routers without the need for topology planning. 

Presently, packet forwarding in computer networks is 
generally accomplished using one of three available tech- 
niques: bridging, routing, or switching. Bridge protocols 
permit bridges to forward packets in either of two ways. In 
one scheme, packets can specify a source route in terms of 
pairs of unique bridge and network identifiers from source to 
destination host. Alternatively, bridges may first establish a 
spanning tree of the network and then send packets over 
branches of such a tree that appear closer to the destination 
hosts. The forwarding table used by a bridge to forward 
packets over the spanning tree has an entry for only those 
destinations for which packets have been processed by the 
bridge. The attractive feature of spanning-tree bridges is that 
packet forwarding is very simple; however, the available 
network bandwidth is used inefficiently. Source-routing 
bridges make better use of the bandwidth available in the 
network, but require a source routing technique that involves 
the hosts. 

Routing pro toco Is permit routers to forward packets either 
as datagrams or as part of virtual circuits. In both 
approaches, routers build and maintain a routing table speci- 
fying the next hop to each destination. In datagram routing, 
each packet specifies a source and a destination using 
addresses that are unique in the entire network or internet; a 
router forwards each datagram by looking up its routing 
table for the next hop on a preferred path to the destination. 

In contrast to datagram routing, with virtual circuit (VC) 
routing routers first establish a path from source to destina- 
tion using a signaling protocol, and then forward packets 
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along the established VCs using VC identifiers. The path 
taken by the VC is determined based on the information 
stored in the routing tables of the routers. Such a path is 
given a virtual circuit identifier and routers maintain a 
s forwarding table listing the next hop of each VC traversing 
the router. Each packet specifies the VC of the packet, and 
routers along the VC consult their forwarding tables to 
forward those packets. A VC is torn down using a signaling 
protocol when the flow of packets ends. 
10 VCs can be specified with unique identifiers. In such 
cases, the origin of the VC assigns a number to the VC and 
the same number is used at every relay router along the VC; 
the VC number becomes unique together with the identifier 
of the VC origin. However, to reduce the size of VC 
15 identifiers, routers along the path of a VC can assign local 
identifiers to the VC. With this approach, each router along 
the path of the VC knows, for every VC local identifier in its 
forwarding table, the next router on the path of the VC and 
the VC local identifier used by the next node for this VC. A 
20 router in a VC swaps the VC local identifier in the header of 
an incoming packet into the VC local identifier expected by 
the next hop in the VC The advantages of VC routing with 
local identifiers are: (a) routers use short identifiers to 
specify and lookup VCs in their forwarding tables, and (b) 
2$ those short identifiers are used to index an entry in the 
forwarding table used to forward packets. Because local VC 
identifiers are short and have fixed length, and because an 
exact match algorithm is used to forward packets, VC 
routing with local VC identifiers can be easily implemented 
30 in hardware. This approach to packet switching has been 
called label swapping or label switching in recent literature. 
See, e.g., B. Davie, P. Doolan, and Y. Rekhter, Switching in 
IP Networks, Morgan Kaufmann (1998). 

Although approaches based on label swapping have 
35 received much attention lately, the basic label swapping 
mechanism and mechanisms to set up states at routers so that 
they can carry out packet forwarding based on label swap- 
ping have been proposed and implemented many times in 
the past since the mid 1970s. VC routing with local identi- 
40 fiers has been studied by Segall (A. Segall and J. Jaffe, 
"Route Setup with Local Identifiers," IEEE Trans. Commun. 
Vol. COM-34, No. 1, January 1986, pp. 45-53), and packet 
switching based on label swapping has been called ID 
swapping (G. Markowsky and F. H. Moss, "An Evaluation 
45 of Local Path ID Swapping in Computer Networks," IEEE 
Trans. Commun. Vol. COM-29, March 1981, pp. 329-336), 
path number and logical record number (M. Schwartz and T 
Stem, "Routing Protocols " IEEE Trans. Commun. Vol. 
COM-28, April 1980). One of the first proposals and imple- 
50 mentations of label swapping was the logical record number 
used by TYMNET in the late 1970s. Id. 

Recent proposals for packet switching include: Internet 
Protocol (IP) switching (P. newman, T. Lyon, and G. 
Minshall, "Flow labeled IP: A connectionless Approach to 
55 ATM," Proc. IEEE Infocom 96, San Francisco, Calif., 1 
1996), tag switching (Y. Rekhter et al., "Tag Switching 
Architecture Overview," Proc. IEEE, Vol. 85, No. 12, 
December 1997), MPLS as being developed by the Internet 
Engineering Task Force, IBM's ARIS, and Toshiba's cell 
60 switching router. All these approaches apply label swapping 
to bypass the network-level lookup of routing tables. 

In the IP switching approach, IP switches, which are 
routers implementing the IP switching approach to packet 
forwarding, must implement a routing protocol to establish 
65 a routing table and packets are first routed using their 
network addresses. When packets for the same flow start 
traversing a given IP switch s, that IP switch can assign a 
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local VC identifier to the packet flow and instruct the 
previous-hop IP switch to use that VC identifier in all 
packets it forwards to s for that flow. In the same way, the 
next-hop IP switch can instruct s to use a local VC identifier 
defined by the next hop in all packets of the flow forwarded 
by s to the next-hop IP switch. When that happens, IP switch 
s can bypass its routing-table lookups for packets in the flow 
and use the label-swapping technique of VC routing with 
local identifiers. 

Tag switching consists of a forwarding component and a 
control component, similar to the VC routing with local 
identifiers scheme. A tag switch is a router capable of 
performing the tag switching mechanism. An entry in the 
forwarding table (called a tag forwarding information base 
or TFIB) consists of an incoming tag (equivalent to a VC 
local identifier) and one or more sub -entries for the tag 
specifying the outgoing tag, interface and link-level infor- 
mation. The link-level information maintained in the TFIB 
consists primarily of the medium access control (MAC) 
address of the next hop. If a switch receives a packet whose 
tag equals a tag in its TFEB, it swaps the MAC address and 
label in the incoming packet with the MAC address and label 
specified in its TFIB and sends the packet over the interface 
also specified in the TFIB. 

The control component of tag switching consists of the 
advertisement among neighbor switches of the binding 
between the address of a destination and the incoming tag it 
uses for the destination. This can be done with a separate tag 
distribution protocol (TDP) or by including the tag assigned 
to a destination as an attachment to the updates sent by the 
routing protocol used in the network. Once a switch assigns 
an incoming tag to a destination, it can establish an entry in 
its TFIB when it receives the tag-to-destination binding from 
the neighbor that it chooses as the next hop to the destina- 
tion. 

All of the above label switching schemes and derivatives 
thereof share certain common features: For example, in each 
of these schemes, a single incoming label (called a VC local 
identifier, path number, or tag, for example) is associated 
with a single outgoing label for purposes of the label 
swapping needed to switch packets towards a given desti- 
nation or for a given VC. Also, the labels refer to destina- 
tions or associations between a source and a destination. The 
mapping established at a node between a destination (or VC) 
and an incoming label (called a VC local identifier, path 
number, or tag, for example) is disseminated among neigh- 
bor nodes by means of explicit exchanges of control infor- 
mation. This signaling is carried out in addition to the 
signaling required to maintain routing tables based on des- 
tination addresses. Further, the unique addresses of both the 
sending and receiving nodes are specified in the headers of 
the packets being forwarded by means of label swapping. 
This information is used to ensure that only the receiving 
node addressed in the packet accepts the packet and asso- 
ciates the label in the packet with the correct outgoing label. 

Furthermore, the descriptions of tag switching and IP 
switching assume the existence of a loop detection mecha- 
nism when switches establish their label-to-destination map- 
pings. A loop consists of the forwarding along a loop of 
packets that set up label-swapping states in the routers, until 
an external action is taken, such as exhausting a "time to 
live" for the packet. The loop detection mechanism adopted 
in these prior schemes consists of using a path vector in the 
header of packets that establishes the binding between the 
labels used to forward traffic. The path vector in a state setup 
packet specifies the routers that have been visited by the 
packet. Another technique used to cope with the looping of 
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state setup packets is to simply decrement a time -to-live 
field in the packet header to allow the packet to visit a 
maximum number of hops trying to set up state. Loop 
detection is still an open issue under discussion for MPLS. 

The differences among the label swapping or label switch- 
ing schemes proposed to date lie in the purpose for which a 
label state is established at the routers (e.g., destination 
oriented, virtual circuits, etc.) and the specific mechanisms 
in the protocols used to set up the label-swapping state at the 
routers. The distribution of label -binding information among 
routers in the prior schemes can be characterized in two 
ways: piggybacking the distribution on top of routing 
protocols, or using a separate protocol for label distribution. 
Because the labels used in the above label switching pro- 
posals refer to either destinations or associations between 
sources and destinations, the routing protocols that can be 
used for the dissemination of such information are distance - 
vector or path-vector oriented. To date, routing protocols 
based on link-state information (e.g., OSPF) have been 
considered to be poor choices for distributing label-binding 
information. B. Davie, P. Doolan, and Y. Rekhter, Switching 
in IP Networks, Morgan Kaufmann, 1998. 

Source routing has also been implemented and used for 
routers, and can be considered a hybrid between datagram 
routing and label switching. With source routing applied to 
routers, the header of a packet specifies the source route 
consisting of the entire path from source to destination; the 
source route is specified in prior routing schemes using the 
unique addresses of the routers in the path to the destination. 
A well-known example of this approach is the source route 
option in IPv4. 

The source route can be obtained by the source of the 
packet in two ways. The router can compute the source route 
locally if it knows the entire network topology; alternatively, 
a path search packet can be sent hop -by-hop to the destina- 
tion to gather the source route, and the destination can send 
a reply back to the source with the source route. All existing 
source routing proposals specify source routes in terms of 
the nodes along the path from source to destination. 

SUMMARY OF THE INVENTION 

In one embodiment, a protocol for a computer network in 
which routing operation codes (ROCs) in headers of packets 
transmitted within the network specify to a receiving router 
which of a number of routing or switching methods to apply 
to forward associated packets. The packets may be for- 
warded in any of the following modes: (a) a broadcast mode, 
(b) a hop -by-hop mode based on receiving node address 
information, (c) a label swapping mode, (d) a source- 
switching mode, (e) a flow switching mode, or (f) a hop- 
by-hop mode based on sending mode address information. 

In the broadcast mode, packets transmitted by a first 
router are accepted by all neighboring routers of the first 
router. In the hop-by- hop mode based on receiving node 
address information, packets are accepted by the receiving 
router if the receiving node address information matches the 
receiving router's media access control address. In the label 
swapping mode, packets are accepted by the receiving router 
if the packets include a media access control address of the 
receiving router, and packets are forwarded from the receiv- 
ing router according to a switching table indexed by a media 
access control address of a transmitting router. In the source 
switching mode, the headers include source routes specified 
in terms of local link identifiers used by routers in the 
network. In the flow switching mode, receiving routers are 
identified using local link identifiers associated with com- 
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munication links between a transmitting router and an mine whether a received packet should be accepted and, if 

intended receiving router, which along with the local link so, which of a number of switching tables to access to 

identifier is used as a criterion upon which a receiving router retrieve information for forwarding the packet within a 

accepts or rejects a packet. computer network. The switching tables may include a 

The local link identifiers may be obtained using either a s source switching table, configured to provide packet for- 

flood search method or through a routing protocol operating warding information which the router is to use to forward the 

within the network. In the source switching mode the packet using a source switching process, and/or a flow 

receiving router forwards a received packet according to a switching table, configured to provide packet forwarding 

local link identifier specified in a source route portion of an information when the router is to forward the packet using 

associated header. «> a A ow switching process. 

In the flow switching node, flow states at routers of the The neighbor identification table is arranged so as to be 

network are established according to information in data indexed using local link identifiers assigned by neighboring 

packets transmitted within the network. The information routers to links communicatively coupling the router thereto 

included in the data packets allows for bindings between and/or to provide pointers to source switching and/or flow 

incoming and outgoing flow labels to be established at each 15 switching tables. The source switching table is arranged so 

of the routers. Such information may include a flow label as to be indexed according to local link identifiers assigned 

and a source route to a destination node in the network. by neighboring routers to links communicatively coupling 

In a further embodiment, forwarding a packet from a first the router thereto. The flow switching table specifies map. 

router of a computer network to a second router thereof is ^ P^F^m flow * t0 OT fM or^f 

, . * j- a ;« 20 identifiers for next hops and associated link-level lnlorma- 

achieved according to a routing operation code specified in uiciniucia iui u^i auu 

a header of the packet. The routing operation code may Uon * 

specify any of the above modes and the value thereof brief DESCRIPTION OF THE DRAWINGS 
determines what other types of information are included in 

the header of the packet. In some cases, the sending node The present invention is illustrated by way of example, 

address information (e.g., its MAC address) is included in an d not limitation, in the figures of the accompanying 

the header of the packet. Also included may be the receiving drawings in which like reference numerals refer to similar 

node address information (e.g., MAC address), receiving elements and in which: 

node — assigned local link identifier, flow label and/or source pj G ^ illustrates an example of an ad hoc wireless 

route. 30 network with routers configured in accordance with the 

In the source switching mode, a sending node obtains a present routing protocol; 
source route to an intended destination using either of a flood piG 2 illustrates an example of a packet header for 
search process or a routing protocol operative within the transporting routing and switching information in accor- 
computer network. In the source switching mode, the packet dance m embodiment of the present invention; 
is forwarded from the first router by reading a source route 35 Urates an example of a router configured with 
specified in the header and substituting a transmitting router taWes m accordance ^th an embodiment of the 
local link identifier and if present, a receiving router local scheme- 
link identifier, included in the header with corresponding P > h .- arinn 
values needed by the second router. In the flow switching FIG. 4 illustrates an example of a neighbor identificaUon 
mode, the packet is forwarded from the first router by 4Q table configured in accordance with an embodiment of the 
reading a source route specified in the header and substitut- present scheme; 

ing a flow label included in the header with a corresponding FIG. 5 presents an example of local link identifiers 

value needed by the second router. assigned by routers of an ad hoc network; 

In some cases, the packet is a data packet that includes FIG. 6 illustrates an example of a neighbor identification 

flow setup instructions for the second router. In such cases, 45 table for one of the routers of the network shown in FIG. 5; 

the packet's header includes a MAC address of the first pjQ 7 illustrates an example of a source switching table 

router and a local link identifier assigned by the first router f or one 0 f tn e routers of the network shown in FIG. 5; 

and may also include a flow label and a source route or a pjQ 8 illustrates an example of a flow switching table for 

flow label and a path traversed field. Qne of the routers 0 f tne network shown in FIG. 5; 

In yet another embodiment, a packet header includes a 50 nG 9 iUustrates another example of a neighbor infor- 

routing operation code configured to indicate to a receiving madon uWe for a rQUter of the network snown in FIG. 5; 

router which of a variety of routine and/or switching meth- 1 1 ♦ u*„ 

lu , " . r y & . 4 , _w c llf ,u FIG. 10 illustrates another example of a source switching 

ods to apply in forwarding an associated packet. Such , Cil _ , etU JL^jlt <.u™„ mr s 

j/ ■* u- *u*a<~ ™«„ ko » nv of* f*\ * table for one of the routers of the network shown in FIG. 5, 

routing and/or switching methods may be any ot. (a) a lQUlw AUI 

broadcast mode, (b) a hop-by-hop mode based on address 55 and . 

information regarding the receiving router, (c) a label swap- FIG. 11 iUustrates another example of a flow switching 

ping mode, (d) a source switching mode, (e) a flow switch- table for one of the routers of the network shown in FIG. 5. 

ing mode, and (e) a hop-by-hop mode based on address DETAILED DESCRIPTION 
information regarding a transmitting router. The routing 

operation code generally determines which of the following eo A scheme for integrating routing and switching in corn- 
fields of information are included in packet header: (a) puter networks is disclosed herein. Although discussed with 
address information of the receiving router, (b) local link reference to certain illustrated embodiments, upon review of 
identifier information assigned by: (i) a transmitting router this specification, those of ordinary skill in the art will 
and/or (ii) the receiving router, (c) a flow label, (d) a source recognize that the present scheme may find application in a 
route, (e) a path traversed, and (f) a pay load type. 65 variety of systems. Therefore, in the following description 
Another embodiment provides a router having a neighbor the illustrated embodiments should be regarded as exem- 
identification table configured to allow the router to deter- plary only and should not be deemed to be limiting in scope. 
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The present scheme enables multiple routing and switch- 
ing methods in the same network. Each packet being routed 
includes a routing operation code (ROC) instructing the 
receiving router which routing or switching method to apply 
to forward the packet. A packet can be forwarded in any of 5 
the following forwarding modes: 

(a) a basic broadcast mode, in which the packet sent by a 
router is accepted by all its neighbors; 

(b) a conventional hop-by -hop mode, in which the packet 
is accepted by a router based on the receiver MAC 
address specified in the packet header and then passed 
to a higher layer for further processing; 

(c) a conventional label-swapping mode, which uses the 
unique MAC address of the receiver specified in the 
packet to decide whether to accept a packet or not, and 
uses the unique MAC address of the sender and a flow 
label to forward an accepted packet according to a 
switching table; 

(d) a source-switching mode, in which the entire source 
route is specified in the packet using local link identi- 
fiers instead of the unique addresses of relay routers as 
is common in previous source routing approaches. This 
use of local link identifiers is further explored in 
co-pending application Sen No. 09/418,700 entitled 
"System for Communicating Labeled Routing Trees to 
Establish Preferred Paths and Source Routes with Local 
Identifiers in Wireless Computer Networks", filed Oct. 
15, 1999, assigned to the Assignee of the present 
invention and incorporated herein by reference; 

(e) a flow-switching mode, which differs from conven- 
tional switching methods based on label swapping in 
that only the unique MAC address of the sender of the 
packet is used and the receiver is identified by means of 
local link identifiers associated with the link between 
the sender and the intended receiver of the packet (see 
the above-cited co -pending application for further 
details); or 

(f) a basic incremental (hop-by -hop) mode, in which the 
packet is accepted by a router based on the unique 
MAC address of the sender and one of multiple local 
link identifiers specified in the packet header. The 
packet is then passed to a higher layer for further 
processing and routing. 

The various forwarding modes are enabled by a flow switch- 
ing protocol. 

In the first three of the above forwarding modes, packets 
are accepted based entirely on the MAC addresses of the 
sender and receiver nodes carried in the packet header. 
However, in the latter three forwarding modes, packets are 
accepted based on local link identifiers carried in the packet 
header. The local link identifiers assigned by the router to 
links with its neighbors and those assigned by the router's 
neighbors to links with the router can be obtained by the 
flow switching protocol through a channel access protocol, 
such as the one proposed in co-pending application Ser. No. 
09/24^,738, entitled "Adaptive Communication Protocol for 
Wireless Networks", filed Feb. 10, 1999, assigned to the 
Assignee of the present invention and incorporated herein by 
reference. 

This flow switching protocol obtains source routes to 
destinations in one of two ways: (a) on demand, in which 
case search messages are sent out to obtain the source routes, 
or (b) by working in combination with a routing protocol 
that can provide source routes. These source routes are 
specified in terms of transmitter-assigned local link identi- 
fiers (LLIDs) given to the links along the path from the 
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source router to the destination. In addition to saving com- 
munication bandwidth, using LLIDs permits the forwarding 
of packets with such source routes to be done using a direct 
index into a forwarding table, which can be easily done in 
hardware. 

The source-switching mode is implemented by packet 
headers specifying a source route in terms of the address of 
the router that originated the packet and a sequence of 
LLIDs specifying the path to a destination, and by routers 
maintaining a table of all LLIDs assigned to the router by its 
neighbors. When a router receives a packet specifying 
source switching, the router accepts the packet based on the 
LLIDs specified for the next hop of the packet, and forwards 
the packet to the neighbor router indicated by the match 
15 between the LLID of the next hop specified in the source 
route and the LLIDs the router assigned to the links with its 
neighbors. 

The flow switching mode is implemented by routers 
maintaining a switching table similar to that used in label 
20 switching. Routers can use either incremental or source- 
switching flow establishment, which processes are described 
below. Both approaches use data packets to establish the 
flow state and the result of sending the flow establishment 
data packet is the establishment of the binding between 
25 incoming and outgoing flow labels at each router in the path 
from source to destination. A packet intended for a flow that 
is already established specifies the flow switching mode in 
the ROC of the packet, the flow label assigned by the 
sending node, the address of the sending node, and the 
30 LLIDs assigned to the fink in use by the sending and 
receiving node. An entry in the flow-switching table is 
erased either after a timeout or the processing of a packet 
with an ROC with a flow-termination code. 

The flow state needed to carry out flow switching is 
35 established at routers by either flow establishment using 
source switching, or incremental flow establishment. With 
flow establishment by source switching, the source of a 
packet stream or flow assigns a flow label to the flow and 
sends a first packet with a source route to the destination of 
40 the flow, the flow label for the flow, and an ROC instructing 
the relay routers to use source switching to forward the 
packet and to establish an entry in their flow switching tables 
for the flow as well. A relay router that receives the packet 
assigns a flow label to the flow, makes an entry in its 
45 flow-switching table with the mapping of the incoming and 
the outgoing flow labels and the associated neighbors along 
the path for the flow, and relays the packet with the same 
ROC, the new flow label, the source route, and an index to 
the source route pointing to the next -hop router as the first 
so non-traversed hop of the source route. 

With incremental (or hop-by-hop) flow establishment, the 
source and each relay router in the path from the source to 
the destination of the flow decides how the packet should be 
forwarded. The ROC of the packet specifies hop-by-hop 
55 flow establishment, which instructs the router to look up its 
routing table to determine the next hop, and to establish the 
binding between incoming and outgoing flow labels. The 
header of the flow-establishment data packet carries a path 
vector specifying the source and the LLIDs of the routers 
60 visited by the flow-establishment data packet. In one 
embodiment of the present scheme, source-switched flow 
establishment is adopted because the amount of information 
in the headers of flow-establishment packets is the same and 
the processing of packets in source switching mode is much 
65 faster than in hop-by-hop routing. 

As in prior schemes, a router can assign a flow label to a 
packet flow in many different ways. One approach consists 
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of using the same flow label for any flow intended for the 
same destination and the same type of service. Although 
many variations of packet switching based on label swap- 
ping and source routing have been implemented in the art, 
the present scheme is unique in a number of ways, including: 

(a) It obtains local link identifiers of all the links needed 
to route or switch packets on a hop-by-hop or source 
route basis. 

(b) It uses local link identifiers to identify the next router 
to process the packet, which makes more efficient use 
of bandwidth while still enabling the packet forwarding 
based on flow labels or source routes to be done in 
hardware. 

(c) It switches packets from source to destination without 
the possibility of looping by specifying the LLIDs 
along the path in the packet headers, and enables this 
type of switching to be done in hardware. 

(d) It can switch packets based on label swapping such 
that: 

(i) The mapping between flow labels and neighbor 
nodes is established on demand (i.e., not for every 
destination or flow). 

(ii) Data packets are used to set up flows, and there is 
no separate signaling protocol needed other than the 
routing instructions in the headers of the packets. 

(iii) There is no looping of data packets used to set up 
flows. The flow switching protocol can be imple- 
mented at the link layer or below. It can be used to 
encapsulate IP packets directly, or to encapsulate 
MAC packets. 

(e) It can switch packets from one router to one or 
multiple neighbors by specifying such neighbors using 
one or multiple local link identifiers. 

The present scheme is well suited for wireless and wired 
networks and the IP internet, in which routers are intercon- 
nected by point-to-point or broadcast links (e.g., local area 
networks) to one another. The present invention is also well 
suited for an ad hoc network that provides a seamless 
extension of the IP Internet to the ad hoc wireless environ- 
ment. FIG. 1 illustrates aspects of an exemplary ad hoc 
internet. 

Ad hoc network 10 may be considered as a number of 
sub-networks 12c, 12b, 12c, which provide an extension of 
the Internet 14 through a number of Internet Radios or IRs 
16a-16t. Each IR 16a-16i is a wireless router with an 
assigned IP address and a MAC address. In general, IRs 
16a-16i operate over one or a multiplicity of radio channels 
using spread-spectrum wireless communication techniques 
common in the art. For example, the IRs 16a-16i may 
operate in one of the unregulated UHF frequency bands, 
thereby obviating the need for operating licenses. Coupling 
of ad hoc network 10 to the Internet 14 is achieved through 
a router 18, which may be operated by an Internet Service 
Provider (IS p )- As shown, a single ISP may operate a LAN 
20 to which multiple IRs are connected. In such a scheme, 
IRs 16a and 166 may act as "AirHeads", providing gateway 
service to Internet 14 via router 18. Some IRs, e.g., IRs 16d 
and 16*? of FIG. 1, may be associated with hosts, 22a, 22b 
and 22c, which can be accessed by any Internet user through 
ad hoc network 10. Like any router, each IR 16a-16i 
processes all messages, changes in the cost of an adjacent 
link, adjacent-link failures, and new-neighbor notifications 
one at a time and in the order in which it detects them. 

Any IR 16a-16i in FIG. 1 can consider another IR to be 
adjacent (we call such an IR a "neighbor") if there is radio 
connectivity between the two IRs and one IR, e.g., IR 16g, 
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can receive and acknowledge packets from the other IR, e.g., 
IR 16/t. Accordingly, a physical broadcast link connecting 
multiple IRs is mapped into multiple point-to-point bidirec- 
tional links defined for the same IRs. Each pair of adjacent 
5 IRs defines two point-to-point bidirectional links between 
them, one in each direction. Each point-to-point bidirec- 
tional link has a head node of the link and a tail node of the 
link. 

As indicated above, the flow switching protocol for use in 
10 ad hoc network 10 in accordance with the present Invention 
supports a variety of packet forwarding modes. This flow 
switching protocol obtains source routes to destination on 
demand, where source routes are specified in terms of 
transmitter-assigned LLIDs regarding the links along the 
15 path from the source router to the destination, or works in 
combination with a routing protocol capable of obtaining 
such source routes. The flow switching protocol then uses 
LLIDs to support the various packet forwarding modes. If 
the flow switching protocol is used in combination with a 
20 routing protocol that can provide source routes to destina- 
tions expressed in terms of the LUDs of the links traversed 
in those routes, the flow switching protocol does not incur 
more traffic than that needed for the transfer of data packets 
themselves. In addition, the use of LUDs in the forwarding 
25 modes of the flow switching protocol enables the imple- 
mentation of all its packet forwarding functions in hardware. 
I. Deriving Source Routes with Local Link Identifiers 

In one embodiment, the present scheme works in combi- 
nation with a routing protocol that incorporates local link 
30 identifiers (LLIDs) as part of the routing information 
exchanged among routers. Such a routing protocol can be 
the Adaptive Internet Routing (AIR) protocol described in 
co-pending application Ser. No. 09/418,700, entitled. "Sys- 
tem for Communicating Labeled Routing Trees to Establish 
35 Preferred Paths and Source Routes with Local Identifiers in 
Wireless Computer Networks", in which routers communi- 
cate labeled routing trees (LRTs). Alink from node x to node 
y in an LRT is given a local link identifier (LLID) by x, the 
head of link (x,y). A second example of a routing protocol 
40 that can be used in combination with the present scheme is 
a modification of a topology-broadcast protocol (e.g., OSPF 
J. Moy, "OSPF Version 2," RFC 1583, Network Working 
Group, March 1994) in which each directed link is assigned 
an LLID by the head of the link, and the LLID of a link is 
45 communicated in every link state update for that link. Still 
another example of a routing protocol that can be used in 
combination with the present invention is a modification of 
a path-vector protocol (e.g., BGP) such that the paths from 
source to destinations are specified in terms of both the 
50 routers used in the paths, as well as the LLIDs of the links 
in the same paths; the LLID of a link in a path is given by 
the head of that link. 

The routing protocol assumed for the operation of the 
present scheme also provides a routing table with the 
55 distance and next hop to each destination. The source routes 
needed by a router can be computed on demand by the 
source of a packet that is to be source switched to the 
destination. Alternatively, the routing table may also include 
the source route specified in terms of LLIDs for each 
60 destination. Multiple routing entries for the same destination 
may be provided, i.e., up to one entry per neighbor per 
destination, and one or multiple routing entries may be 
provided for each type of service defined in the system. 
The preferred approach for this embodiment would be 
65 based on its combined use with the Adaptive Internet 
Routing (AIR) protocol, simply because of the performance 
improvements derived from AIR compared to the other three 
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alternatives listed above. Nevertheless, in another embodi- which the packet should be dropped to prevent packets from 

ment of the present invention, no routing protocol is remaining in the network indefinitely. The reliability (R) 

assumed for its operation, and routes to destinations speci- field 36 specifies the degree of reliability with which the 

fied in terms of LLIDs may be obtained on demand. In this packet must be successfully forwarded by the router. The 
case, a router that originates a packet for a destination and 5 priority (P) field 38 specifies the priority that the packet 

has no routing information for that destination may send ***** * *f ^ V^^H^ ™ °1 

search packets to its neighbors in order to find an intended ™* type (LOAD) field 40 is optional and specifies 

, . K ™. li* . , • * uu the type of payload that follows the header; if the field is 

destination The search ^ packet sen i to , a given .neighbor ^ the payload is assumed to be a packet using a 

specifies: the address of the intended destination, the address defiDcd ^ protocol such as the REALM protocol 
of the intended receiver of the packet, and a source route. 10 described m spending application Ser. No. 09/248,738, 

The source route of the packet is specified in terms of the entitled "Adaptive Communication Protocol for Wireless 

address of the source router and the LUD assigned by the Networks". 

source router to the link with its neighbor. A router receiving ^h c routing operation code (ROC) 42 specifies the 
a search packet that does not have a routing entry for the instruction (e.g., in binary code format) to be used on the 
intended destination forwards the packet to each of its 15 packet, i.e., how the packet should be processed. The value 
neighbors other than the one from which the packet is specified in the ROC field 42 determines which other fields 
received, and the packet specifies: the address of the should be present in the header 30. The routing and switch- 
intended destination, the address of the intended receiver of ing modes include but are not limited to: basic broadcast 
the packet, and a source route with the LUD of the link from mode (ROC=0), hop-by-hop mode (ROC=l), label swap- 
the sending router to the intended receiver added. A router 20 ping mode (ROC=2), source switching mode (ROC=3), flow 
receiving the search packet that has a source route (specified switching mode (ROC=4), source-switched flow establish- 
in terms of LLIDs of the links in the path to the destination) ment (ROC=5), and incremental flow establishment (ROC= 
sends a reply with the entire source route consisting of the 6). 

source router address and the sequence of LLIDs for all the The transmitter's MAC address (XADD) field 44 idenu- 
links in the path to the destination. 25 fies the sender of the packet and should always be present in 

II. Information Contained in Packet Headers a packet header 30. The receiver's MAC address (RADD) 

In the present scheme, the header of a packet specifies a field 46 is optional and identifies the receiver of the packet; 

switching or routing instruction that instructs the router to the RADD is present in the header when the ROC specifies 

process the packet in one of multiple possible switching or a routing or switching mode based on the sender and 

routing modes, and specifies the additional information 30 receiver MAC addresses; examples of these modes are 

needed for the router to carry out the operation. Io an IP normal packet routing and tag switching, 

internetwork or an ad hoc network extending the IP Internet, The transmitter-assigned link identifier (XLID) field 48 is 

the flow switching protocol of the present invention could be optional and is present when the ROC specifies a forwarding 

used to carry IP packets or it could be used to carry operation in terms of the LLID of the link to the next hop for 

MAC-layer packets that in turn encapsulate IP packets. For 35 the packet. The XLID specifies the local link identifier 

purposes of clarity, we omit the description of conventional assigned by the transmitter to the link with one of its 

framing and error detection functionalities that may also be neighbors. A router cannot assign the same XLID to more 

present in the packet header, and describe the operation of than one link with a neighbor. 

the flow switching protocol in general terms applicable to The receiver-assigned link identifier (RLID) field 50 is 
the forwarding of IP packets and MAC-layer packets. 40 optional and specifies the local link identifier assigned by the 
FIG 2 presents a canonical packet-header format, which intended receiver of the packet to the link with the trans- 
illustrates the type of routing and switching information mitting router. An RLID reported by router x in a packet 
used in one embodiment of the present scheme, as well as destined for neighbor y is, therefore, the XLID that x knows 
the combination of the various types of information. Various y has assigned to the link (y, x). The RLID field 50 is present 
fields in the canonical packet header 30 can be required 45 in the packet header 30 when the ROC specifies the source 
fields or optional fields. Some of the innovative features of switch or flow switch mode and the lookup at the receiver is 
canonical packet header 30 stem from the use in various accomplished based on receiver-assigned link identifiers, 
combinations of switching and routing instructions, local When RLIDs are used in packet headers, a router accepts the 
link identifiers, source routes specified with local link packet based on the XADD, XLID, and RLID fields, 44, 48 
identifiers, and other forwarding labels, to enable different 50 and 50, of the header. 

routing and switching operations on data packets within the The flow label (FL) field 52 is optional and is present 

same unifying packet processing framework. when the ROC specifies the flow switching mode. The FL 

The canonical packet header description shown in FIG. 2 specifies the label assigned to a flow of packets by the 

omits framing and error checking fields that may be present transmitting router. To minimize the number of flow labels 

in an actual implementation. It should be evident to those of 55 routers have to remember, it may be assumed that a router 

ordinary skill in the art that, depending on a variety of assigns the same flow label to packets of the same traffic 

implementation issues (e.g., bandwidth available in the class flowing to the same destination, 

communication finks) this canonical format can be imple- The source route field 54 is optional and is present when 

mented in a variety of ways, ranging from the number of bits the ROC specifies any forwarding operation involving 

used in each field and the the position of the fields in the 60 source switching. It may include three sub-fields (not shown 

packet header, to the use of extension headers in order to in detail), a hop count (HC) specifying the number of entries 

simplify the processing of the most commonly transmitted in the source route, a pointer to the next hop (PNH) 

types of packets. In addition, the canonical packet header 30 indicating the XLID that the receiving router should read to 

described herein can be part of a larger packet header. forward the packet, and a source route (SR) consisting of 

Aversion (V) field 32 specifies the version of the protocol 65 one or more XLIDs. 

to be used to process the packet. The time to live (TTL) field The path-traversed field 56 is optional and is present when 

34 specifies an upper bound in terms of hops or time, beyond the ROC specifies hop-by-hop flow establishment. It 
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includes of a hop count specifying the number of routers 
visited by the packet, and the ordered sequence of MAC 
addresses of the routers visited. 
III. Switching Information Maintained at Routers 

The switching information maintained at routers is used to s 
switch packets below the IP layer. As will be apparent to 
those of ordinary skill in the art from the subsequent 
description, the introduction of XUDs and RLIDs in the 
present scheme reduces the amount of bandwidth consumed 
by packet headers and, more importantly, enables the imple- 10 
mentation of flow and source switching modes in simple 
hardware. This makes packet switching according to the 
present invention much faster than routing packets by table 
lookups, even if the fast table lookup technology of prior 
schemes is utilized. 15 

As shown in FIG. 3, each router 60 maintains three types 
of switching tables: a neighbor identification table (NTT) 62, 
a source switching table (SST) 64 and a flow switching table 
(FST) 66 for each neighbor. The NIT 62 permits a router to 
determine if a received packet is intended for that router and, 20 
if so, which switching table to use to forward the packet. The 
SST 64 specifies the forwarding instructions a router should 
follow to forward packets in source switching mode. Each 
FST 66 specifies the mapping from a given incoming flow 



routers may use the same XUD for the same router. For 
example, routers B and D assign XUD-1 for their links with 
router A, and routers A and B assign XLID=2 for their links 
with router D. 

Continuing with the same example network FIG. 6 shows 
the NIT 62 A at routerAof FIG. 5. Note that the index values 
used in the NIT 62 A are those assigned by router A's 
neighbors to the links incident into router A, not XUD 
values assigned by router A to links outgoing from router A 
to its neighbors. In the present example, router A has two 
neighbors, routers B and D, using the same value of XLID-1 
to refer to links incident into router A. This is not a problem 
due to the array structure of NIT 62A, which specifies the 
MAC address of each neighbor of router A using a given 
XLID to denote an incident link into router A and a pointer 
to the proper FST, which is to be used to process packets in 
flow switching mode. Note also that the NIT 62 A of router 
A has only four table entries, corresponding to four neigh- 
bors (B, D, C, and E). 

Because a source route in a packet header specifies the 
next hop to which the receiving node should forward the 
packet, an SST 64 is indexed on the XLID values that the 
router assigns to its outgoing links with neighbors. Each 
entry in an SST 64 specifies an outgoing interface and 



label to the outgoing flow label, the necessary LUDs to 25 link-level information for the transmission of the packet to 



identify the next hop, and the necessary link-level informa 
tion for the transmission of the packet to the next hop. 

Below are presented two examples for the maintenance of 
switching information in the present routing scheme, which 
embodiments differ depending upon whether or not receiver- 
assigned LLIDs are used for source switching or flow 
switching. 

IIU. Information Stored for Switching 
A, Using Transmitter-assigned LUDs 



the next hop. Continuing with the same example network of 
FIG. 5, FIG. 7 shows the SST 64A at router A; the MAC 
addresses of neighbor routers are shown in parenthesis since 
they are not stored in the SST Note that the four entries 
30 indexed by XLID value correspond to the four links going 
from router A to its neighbors. 

As earlier stated, a router maintains a flow switching table 
(FST) 66 for each neighbor router. The FST for a given 

neighbor is indexed according to the values of the incoming 

In one embodiment "of the present scheme, only 35 flow labels used for flow switching. For a given value of an 
transmitter-assigned LLIDs are used to identify links incoming flow label, the FST specifies the value of the 
between neighbors. In this case, the RLE) field 50 is not outgoing flow label, link-level information for the transmis- 
used for flow switching or source switching, and the NIT 62 sion of the packet to the next hop, and the value of the XUD 
is indexed according to links incident into the router and to be used when a packet is forwarded to the next hop in flow 
provides pointers to the SST 64 and the FST 66 as needed. 40 switching mode. The use of the latter entry is unique in the 
More specifically, the keys for the NIT are the XLIDs present scheme relative to all prior packet switching tech- 
reported by the neighbors of the receiving router for their niques based on label swapping. 

finks to that router. One or more neighbors of the subject Using the same example network of FIG. 5, FIG. 8 shows 
router may use the same XLID value 48 to label their links the FST 66A at router A for its neighbor router D. It is 
to the router. Accordingly, as shown in FIG. 4, the entry 68 45 assumed that two flows going from D to A have been 
in the NIT 62 is an array consisting of zero or more array established already. One flow is identified with the incoming 
entries, each array entry corresponding to a neighbor that flow label fll and the other with incoming flow label fl2. For 
uses the value of the XLID for a link to the router and fll, the forwarding instruction in the FST 66A specifies that 
including: (a) the MAC address of the neighbor and (b) a router A should swap fll for fix when it forwards a packet for 
pointer to the FST of the neighbor. In one embodiment, a 50 the corresponding flow, and that it should specify XLID=1 
router has relatively few neighbors (e.g., up to 64 neighbors) in the packet header and forward the packet to neighbor 
and searching on the XUD as the key is, consequently, very router B. The routing instruction also specifies all the 
fast. Furthermore, if a router has N neighbors, the total necessary link-level information, which is dependent on the 
number of array entries in the NIT 62 is N; hence, in the type of network being used (e.g., an ad hoc network or a 
worst case a router has to search in a list of up to N entries 55 wired network). 



(either all its neighbors use different XLIDs for their links to 
the router, or all its neighbors use the same value of XLID 
for their links to the router). 

FIG. 5 shows an example network consisting of six 
routers (A-F) connected by point-to-point links. Circles 
indicate routers and lines indicate the links between them. 
The label inside a circle indicates the MAC address of the 
router, and the arrows and labels next to the links connecting 
the routers indicate the XLIDs assigned by a router to each 
fink with a neighbor. For example, router A assigns XLID-4 
to its link with router E. Note that no router assigns the same 
XLID to more than one link, and that multiple neighbor 



III.2. Information Stored for Switching Using Receiver- and 
Transmitter-assigned LLIDs 

In an alternative embodiment of the present scheme, 
routers use the receiver- assigned link identifier (RUD) field 
60 50 to identify a given link with the local link identifiers 
assigned by each end of the link. The headers of packets to 
be forwarded according to source switching and flow 
switching specify the RUD in addition to the XLID. 
In this embodiment, the NIT at each router is indexed by 
65 the RLID, Le., the local link identifier assigned by the router 
to its outgoing links, which is specified by a neighbor router 
in the header of the packet. The NIT entry for a given value 
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of the RLID specifies the MAC address of a neighbor, the 
XLJD assigned to the link by the router, and a pointer to the 
FST for that neighbor. Continuing with the same example 
network of FIG. 5, we note that any router knows the LLID 
assigned by each of its neighbors to the link from the 
neighbor to the router. Router A, for example, knows that 
router E assigned the LLID=3 to the link from E to A. This 
information can be made available to the flow switching 
protocol by different means, including an underlying chan- 
nel access layer and a routing protocol. 

FIG. 9 shows the NTT 70Aat router Aof FIG. 5. Note that 
the index values used in the NTT 70A are now the RLIDs 
assigned by the subject router to each of its neighbors, and 
all such RUDs are different from each other. The NIT 70A 
specifies the MAC address of a neighbor, the LLID assigned 
by the neighbor to the link with the router, and a pointer to 
the FST used when packets are flow switched. 

A router accepts a packet based on the values of the 
XADD, XLID, and RLID fields, 44, 48 and 50, of the packet 
header. More specifically, the RLID field 50 identifies the 
entry of the NIT that should be further examined, if no entry 
of the NIT is labeled with a value equal to the RLID of the 
packet, the packet is discarded. If the XADD and XLID do 
not correspond to the MAC and LLID values of the NIT 
entry specified by the RLID value, the packet is discarded. 

The SST is indexed on the XLID values that the subject 
router assigns to its outgoing links with neighbors. Each 
entry in the SST specifies the LLID assigned to the link by 
the neighbor router (RLID to be used in a packet header), 
outgoing interface, and link- level information for the trans- 
mission of the packet to the next hop. Continuing with the 
same example network of FIG. 5, FIG. 10 shows the SST 
72A at router A 

The FST for a given neighbor specifies, for a given value 
of an incoming flow label, the value of the outgoing flow 
label, link-level information for the transmission of the 
packet to the next hop, and the value of the XLID and RLID 
to be used when a packet is forwarded to the next hop in flow 
switching mode. Using the same example network of FIG. 
5, FIG. 11 shows the FST 74A at router A for its neighbor 
router D. It is assumed that two flows going from D to A 
have been established already. One flow is identified with 
the incoming flow label fll and the other with incoming flow 
label fl2. For fll, the forwarding instruction in the FST 74A 
specifies that router A should swap fll for fix when it 
forwards a packet for the corresponding flow, and that it 
should specify XLID-1 in the packet header and forward the 
packet to neighbor router B. 
IV. Packet Forwarding Modes 

We now describe how the present scheme supports a 
number of routing and switching modes of packet forward- 
ing operations based on the information specified in packet 
headers and routing and switching information maintained at 
routers. The overall handling of packets by the present flow 
switching protocol can be described by the following 
pseudo-code. 

Procedure Process-Packet 

{called by packet arriving at router} 

do CASE 

ROG=0: call Broadcasting 

ROC=l: call Hop_by_Hop 

ROC=2: call Label_Swappiog 

ROC=3: call Source_Switching 

ROC=4: call Flow_Switching 

ROC-5: call Source_Switched_Flow 
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ROC=6: call Incremental_Flow 
ROC«7: call Incremental_Switching 
End Process-Packet 

s In the following, we describe each packet forwarding mode 
used to process packets. This description considers the two 
alternative embodiments discussed above. 
IV.l. Basic Broadcasting and Conventional Point-to-Point 
Transmissions 

10 A router sends a packet with a header specifying ROC=*0 
to force all its neighbors process the packet and pass it to a 
higher layer, where additional processing takes place. A 
router receiving a packet with its header specifying ROG=0 
simply accepts the packet and passes it to the higher layer. 
This packet-forwarding mode could be used to support 

35 network-layer control functions requiring routers to com- 
municate with all their neighbors. 

The point-to-point mode is used to simply pass informa- 
tion from one router to one of its neighbors or to a subset of 
its neighbors using a multicast MAC address. In this case, 

20 the header of the packet specifies ROC-1 and includes the 
RADD field 46. A router that receives the packet with 
ROC=l accepts the packet if the RADD in the packet header 
equals the router's own MAC address or a multicast MAC 
address to which the router belongs. In such a case, the 

25 accepted packet can be routed at the higher layer (e.g., the 
IP layer) using a standard routing table based on destination 
addresses. The final destination of the packet or a conven- 
tional source route should be included in the payload that 
follows the packet header, just as is the case for IP packets 
encapsulated in frames that are formatted according to IEEE 
Standard 802.3. 

IV.2. Conventional Label Swapping 

In the label-swapping mode, the header of a packet 
specifies ROC=2 and includes the RADD and FL fields 46 
and 52. Packets are switched to their destinations in much 

35 the same way as in other protocols based on local VC 
identifiers. A router accepts a packet based on the RADD in 
the header, and the accepted packet is forwarded by swap- 
ping the incoming flow label in the header with the outgoing 
flow label stored in a flow switching table stored at the router 

40 and indexed by the incoming flow label and the MAC 
address of the neighbors of the router. In this mode of 
operation, the difference between the present scheme and 
earlier ones stems from the way in which routers can 
establish the label swapping state using source switching. 

45 IV.3. Source Switching 

The source switching mode is unique to the present 
scheme. In source switching mode, the router that originates 
the packet first obtains the source route to the intended 
destination in terms of the LLIDs assigned to the links along 

50 the path from source to destination. As earlier established, 
the router obtains this information either through the routing 
protocol used in combination with this routing scheme, or by 
means of control search packets disseminated in the net- 
work. 

55 Once a router has a source route based on LLIDs to the 
intended destination, it forwards a packet specifying the 
source-switching mode (ROC=3) to the next-hop router 
along the source route to the destination. The header of such 
a packet also contains the XLID assigned by the router to the 

60 link with the next hop of the source route, the router's own 
MAC address, the source route to the destination specified 
as a sequence of XLIDs, and a pointer into the source route 
informing its neighbor which is the next hop that the 
neighbor should examine. If receiver-assigned LLIDs are 

65 used, the header also contains the RLID assigned by the 
intended receiver to the link with the router sending the 
packet. 
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A packet is source switched at every hop by reading the 
source route in the packet header and substituting the XLID, 
and if present the RLID, specified in the header to allow the 
router to accept the packet with the XUD, and RLID if 
present, needed by the next hop. 

Note that although LLIDs are swapped at each router, the 
labels used in source switching are very different than those 
used in the label switching approaches of the past, because 
they refer to the links over which the packet must flow, 
rather than the destination, or association from source to 
destination, for which the packet is intended. 

Another approach to source switching would consist of 
specifying the MAC address of the next hop in the source 
route along with the source route specified in terms of 
LLIDs. Such a variation of the source switching approach 
could be used when channel bandwidth is not at a premium. 
The packet header in this forwarding mode would specify 
the source route field and would substitute the XLID field 48 
for the RADD field 46. A router can then accept a packet 
based on the MAC address of the intended receiver specified 
in the header. However, given that LUDs have to be used to 
provide a simple index to the SST, there may be little or no 
advantage to using the MAC address of the receiver rather 
than the LLID of the link to the same router. 
IV.3.a. Source Switching Using Receiver- and Transmitter- 
assigned LLIDs 

The switching operation at a router when receiver- 
assigned LLIDs are used in packet headers consists of 
accepting the packet and forwarding the packet, if accepted. 
The following pseudo-code specifies the procedure formally, 
which operations can be implemented in hardware or soft- 
ware. 

First, the router decides whether to accept the packet or 
not based on the XADD, XLID, and RLID fields, 44, 48 and 
50, of the packet header, which must match with one entry 
in the NIT 62 of the router. The XADD and XLID identify 
the link from neighbor to router; however, to permit the 
router receiving the packet to scan its NIT 62 using a simple 
index, the RLID given to the link from the router to the 
neighbor is also included in the packet. Accordingly, the 
router can scan its NIT 62 using the received RLID as the 
key, and decide whether or not to accept the packet by 
matching the XADD and XLID from the packet with the 
MAC address and LLID stored in its NIT 62. 

If the packet is accepted, the router scans its SST 64 based 
on the XLID of the packet. To forward the packet to the next 
hop, it advances the PNH of the source route field 54 of the 
packet, and substitutes the XLID and RLID received with 
those expected by the next hop. The packet is then forwarded 
according to the link-level information for the next hop 
maintained in the SST 64. 

The key advantage of this approach to source switching is 
that the lookup in the NIT 62 is based on a simple key, and 
the added overhead of including the receiver-assigned LLID 
of a link (RLID) is minimal, because a router has a relatively 
small number of neighbors, which means that the lengths of 
the XLID and RLID fields 48 and 50 are small. 
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-continued 



XADD: Transmitter's MAC address specified in packet header. 

NTT. did: Any LLID in NTT assigned by router to a link 

with a neighbor. 
NIT(RLID): Row of the NTT specified by RLID. 

NTT(RUD).mnc: MAC address stored in NTT entry specified by RLID 

value. 

NTT(RLlD)jtlid: LUD assigned by neighbor to link with router 

and stored in NTT entry specified by RLID value. 
PNH(SR): Local link identifier specified by the pointer 

to the next hop (PNH) in packet header. 
SST.xlid: Any local link identifier in SST 

assigned to an outgoing link. 
SST(XLID).rlid: LLID assigned by neighbor to its link with router 

and stored in SST entry specified by XUD value. 
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50 



55 



Procedure Source__Switching 

{called when packet with R0O3 is received} 

1. If (XADD!=NIT(RLJD).mac or XLID!=N1T(RLID) 
.xlid) then reject packet and return 

2. If (PNH(SR)!=SST.xlid) then reject packet and return 

3. XL1D<-PNH(SR) 

4. RLID<-SST(XLID).rlid 

5. PNH<-PNH+1 

6. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switching 

IV.3 Jb. Source Switching Using Transmitter- Assigned Local 
Link Identifiers 

A router receiving a packet specifying source switching 
may process the packet using the simple procedure specified 
in pseudo-code below. First, the router decides whether to 
accept the packet or not based on the XADD and XLID 
fields, 44 and 48, of the packet header, which must match 
with one array entry 68 in its NIT 62. The XLID and XADD 
uniquely identify a receiver router, because MAC addresses 
are unique and no router assigns the same XLID to more 
than one neighbor. Furthermore, searching the NIT 62 for a 
match between the packet's XLID and a LLID assigned to 
the router by one of its neighbors is very fast, because the 
router can have no more LLIDs assigned to it than the 
neighbors it has, and given a match with the packet's XLID 
searching for a match between the packet's XADD and the 
MAC addresses of the neighbors that assigned the same 
LLID to the router is very fast, because only a subset of the 
router's neighbors can use the same LLID for their links to 
the router. 

If the packet is accepted, the router scans its SST 64 based 
on the XLID of the packet. To forward the packet, the router 
substitutes the XLID with the LLID corresponding to the 
PNH value of the source route and increments the PNH of 
the packet header. The packet is then forwarded according to 
the link-level information maintained in the SST 64 for the 
next hop in the route. The following pseudo-code formally 
specifies this simple procedure. 



SR: Source route specified in packet header. 

NIT: Neighbor identification table. 

SST: Source switching table. 

XLID: Transmitter-assigned link identifier specified in 

packet header. 

RLID: Receiver-assigned link identifier specified in 

packet header. 



60 



SR: 

PNH(SR): 

NIT: 
SST: 
XUD: 



XADD: 



Source route sped tied in packet header. 

Local link identifier specified by the pointer to the next 

hop (PNH) in packet header. 

Neighbor identification table. 

Source switching table. 

Transmitter-assigned link identifier specified in packet 
header. 

Transmitter's MAC address specified in packet header. 
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-continued 



-continued 



NTTlxUd: Any LLID in NIT assigned by a neighbor to the link 

with the router. 
NTT(XLID): Row of the NTT specified by XLID. 
SST(XLID): Row of the SST specified by XLID. 
NIT(XLID).mac: Any MAC address in the row of the NTT specified by 

XLID. 

SST.xlid: Any local link identifier in SST assigned to an 

outgoing link- 



Procedure Source_Switching 
{called when packet with R0O3 is received} 

1. If (XLID!=NIT.xlid) then reject packet and return 

2. NlT(x)<-l 

3. found< -false 

4. While not (found) do 
found<-NIT(x).mac and XADD 
NIT(x)<-NIT(x)+l 

5. If (not found) then reject packet and return 

6. If (PNH(SR)!=SST.xlid) then reject packet and return 

7. XUD<-PNH(SR) 

8. PNH<-PNH+1 

9. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source__Switching 

The above procedure can also be implemented in hardware 

or software. 

IV.4. Flow Switching 

The flow switching mode is unique to the present scheme 
and provides for packet switching using label swapping 
without the need to specify the MAC address of the receiver 
of the packet. This is accomplished by using the same 
approach used for source switching to determine when a 
packet should be accepted. If a match is found in the NIT 62 
for the tuple formed by the XLID and XADD of the packet, 
or for the tuple formed by ROD, XLID, and XADD, if 
receiver-assigned LLIDs are used, the NIT 62 provides a 
pointer to the flow switching table (FST) 66 maintained for 
the neighbor that sent the packet. 

The FST 66 maintains the mapping between the flow label 
specified in the packet and the flow label to be used for the 
next hop, together with the LLID of the link to the next hop 
and any outgoing link-level information. If RLIDs are used 
in packet headers, the FST 66 also specifies the RLID to be 
included in the header of the outgoing packet. 

To forward a received packet, the subject router substi- 
tutes in the outgoing packet the values of either FL and 
XLID, or FL, XLID, and RLID in the header of the received 
packet with the entries specified in the FST 66 for the next 
hop of the packet. The following pseudo-code specifies the 
procedure used for flow switching when RLIDs are included 
in packet headers. 
NIT: Neighbor Identification Table 



FST_p: The flow switching table specified 

by the pointer p. 
XLID: Transmitter- assigned link identifier specified in 

packet header. 

RUD: receiver-assigned link identifier specified in 

packet header. 

FL: Flow label specified in packet header. 



FST_p(IFL): Forwarding instruction in FST_p for incoming flow 

label specified by IFL. 
5 FST_p.ifl; Any incoming flow label in FST__p. 

FST_jj(FL).ofl: Outgoing flow label in the entry for incoming flow 

label FL in FST_p. 
FST_p(FL)jclid: LLID assigned by router to link with neighbor and 

stored in FST_p entry specified by FL 
FST_p(FL).rlid: LLID assigned by neighbor to link with router and 
10 stored in FST_p entry specified by FL 

NrrCRLTD).mac: MAC address stored in NIT entry specified by RLID. 
NIT(RLID)jtlid: LLID assigned by neighbor to link with the router in 

NTT entry specified by RLID. 
NlT(RLID).ptr: Pointer to an FST in NIT entry specified by RLID. 
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30 



Procedure Flow_Switching 

{called when packet with ROC=4 is received} 

1. If (XADD!-NIT(RLlD).mac or XLID!-N1T(RLID) 
.xlid) then reject packet and return 

2. p<-NIT(RUD).ptr 

3. If (FL!-FST_j).ifl) then reject packet and return 
4. 1FL<-FL 

5. XLID<-FST__p(FL).xlid 

6. RLID<-FST_p(FL).rlid 

7. FL<-FST_p(FL).ofl 

8. Forward packet according to forwarding instructions 
for FST_p(IFL) 

End Flow_Switching 

The following pseudo-code specifies the procedure used for 
flow switching when no RLIDs are used in packet headers. 



35 

NTT: 
FST_p: 

XLID: 

FL: 

XADD: 

NTT. xlid: 

45 NIT(XLID): 
NTT(XLID).mac: 

FST_p.ifl: 
FST_p(FL).ofl: 

50 FST_p(FL).xlid: 

NIT(XLID,XADD).ptr: 



Neighbor identification table. 

The flow switching table specified by the 

pointer p. 

Transmitter-assigned link identifier specified in 
packet header. 

Flow label specified in packet header. 
Transmitter's MAC address specified in packet 
header. 

Any LUD in NIT assigned by a neighbor to the 

link with the router. 

Row of the NTT specified by XLID. 

Any MAC address in the row of the NTT 

specified by XLID. 

Any incoming flow label in FST__p. 

Outgoing flow label in the entry for incoming 

flow Label FL in FST_p. 

LLID in the entry for incoming flow label FL 

in FST_p. 

Pointer to an FST for neighbor with MAC 
address that matches XADD in NTT entry 
specified by XLID. 



60 



65 



Procedure Flow_Switching 

{called when packet with ROC=4 is received} 

1. If (XLID!=rsnTxlid) then reject packet and return 

2. NIT(x)<-l 

3. found<-false 

4. While not (found) do 
found<-NIT(x).mac and XADD 
NIT(x)<-NTT(x)+l 

5. If (not found) then reject packet and return 

6. p<-NIT(XUD,XADD).ptr 

7. If (FL!-FST_^).ifl) then reject packet and return 
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8. FL<-FL 

9. XUD<-FST_p(FL).xlid 

10. FL<-FST_p(FL).ofl 

11. Forward packet according to forwarding instructions 
for FST(IFL) 

End Flow_Switching 

IV5. Incremental Switching 

With incremental switching, a packet is accepted by a 
router based on the XADD, XLID, and RUD specified in the 
header using the same approach described for source switch- 
ing. The accepted packet is then passed to a higher layer for 
further processing, which may include routing at the net- 
work layer. 

V. Establishing Flow State at Routers 

In the present scheme, flow state may be established either 
incrementally or using source routes, and establishing flow 
state amounts to another packet forwarding mode, i.e., flow 
state is established by forwarding data packets. A router that 
decides to establish flow state along a loop-free path to a 
destination first obtains the source route to the destination in 
the same way as in source switching mode. Once the router 
obtains a source route, it sends a source-switched data 
packet with flow setup instructions, so that flow state can be 
set as the packet traverses the source route to the destination. 
The header of the packet specifies: the source-switched flow 
establishment operation code (ROC-5), the MAC address of 
the transmitting router (XADD), the XLID of the link to the 
next hop, a flow label (FL), and the source route field 54. 

When a router receives a packet with the source-switched 
flow establishment operation code, it establishes flow state 
and forwards the packet according to source switching. The 
router determines whether to accept the packet or not based 
on the XADD, XLID, and RLID fields, 44, 48 and 50, of the 
header, or the XADD an XLID fields, 44 and 48, only, if no 
RLIDs are used to implement source switching and flow 
switching. If the packet is accepted, the receiving router 
establishes an entry in the FST 66 for its neighbor; in such 
an entry the FL received in the packet is mapped into an 
outgoing flow label created by the router and the XLID and, 
if applicable, the RLID of the next hop in the source route 
specified in the packet. The router forwards the packet as in 
the case of source -switching mode, together with the swap- 
ping of flow labels. 

The following pseudo-code describes the procedure used 
when RLIDs are used in packet headers in the present 
scheme. 



SR: 
NTT: 
SST: 
XLID: 

RLID: 

XADD: 
NIT.rlid: 

NTT(RLID): 
SSTfXLID): 
NIT(RLID).mac: 

NTT(RLID).xtid: 

PNH(SR): 
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-continued 



SST.xlid: Any local link identifier in SST assigned to an 

outgoing lint. 

5 SST(XLTD).rlid: UJD assigned by neighbor to its Knk with router and 
stored in SST entry specified by XLID value. 



Procedure Source__Switched_Flow 

{called when packet with R0O3 is received} 

1. If (XADD!=NIT(RLID).mac or XLID NIT(RLID) 
.xlid) then reject packet and return 

2. If (PNH(SR)!oSST.xlid) then reject packet and return 

3. p<-NIT(RUD).ptr 

4. Create new entry in FST_p for FL 

5. XLJD<-PNH(SR) 

6. RLID<-SST(XLJD).rlid 

7. PNH<-PNH+1 

8. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switched_Flow 



45 



Source route specified in packet header. 
Neighbor identification table. 
Source switching table. 

Transmitter- assigned link identifier specified in packet 
header. 

Receiver-assigned link identifier specified in packet 
header. 

Transmitter's MAC address specified in packet header. 
Any LLID in NTT assigned by router to a link with a 
neighbor. 

Row of the NTT specified by RLID. 

Row of the SST specified by XLID. 

MAC address stored in NIT entry specified by RLID 

value. 

LLID assigned by neighbor to link with router and 
stored in NIT entry specified by RUD value. 
Local link identifier specified by the pointer to the next 
hop (FNH) in packet header. 
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The following pseudo-code specifies the procedure used 
to establish flow state with source switching when RLIDs 
are not used in packet headers. 



30 

SR: 

PNH(SR): 

NTT: 
SST: 
35 XLID: 

XADD: 

FL: 

NTTfXLID): 
40 NlT(XLID).inac: 

SST.xlid: 

Nrr(XLID^ADD).ptn 



FST_p(FL).ofl: 
FST_p(FL).xlid: 



Source route specified in packet header. 
Local link identifier specified by the pointer to 
the next hop (PNH) in packet header. 
Neighbor identification table. 
Source switching table. 

Transmitter-assigned link identifier specified in 
packet header. 

Transmitter's MAC address specified in packet 
header. 

Flow label specified in packet header. 
Row of the NTT specified by XUD. 
Any MAC address in the row of the NTT 
specified by XLID. 

Any local link identifier in SST assigned to an 
outgoing link. 

Pointer to an FST for neighbor with MAC 
address that matches XADD in NTT row given 
by XLID. 

Outgoing flow label in the entry for incoming 
flow label FL in FST_p. 
LLID in the entry for incoming flow label FL 
in FST_p. 



Procedure Source_Switched_Flow 

{called when packet with ROC=5 is received} 

1. If (XLID!-NlTxlid) then reject packet and return 

2. NIT(x)<-l 

3. found<-false 

4. While not (found) do 
found<-NIT(x).mac and XADD 
NIT(X)<-NIT(x)+l 

5. If (not found) then reject packet and return 

6. If (PNH(SR)!=SST.xlid) then reject packet and return 

7. p<-NIT(XLID,XADD).ptr 

8. Create new entry in FST_p for FL 

8.0. FST_p(FL).ofl<-new ofl for FST_p 
S.b. FST_p(FL).xlid<-PNH(SR) 

9. XLID<-PNH(SR) 
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10. PNH<-PNH+1 

11. FL<-FST_p(FL).ofl 

12. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switched_Flow 

If the present scheme is used in combination with a 
routing protocol, flow state can also be established incre- 
mentally. In this case, the router obtains the next hop to a 
destination from its routing table and forwards a data packet 10 
with the following control information in its header: the 
ROC=6, the MAC address of the router (XADD), the XLID 
of the link to the next hop, a flow label (FL), and the 
path-traversed field 56. The path-traversed field 56 specifies 
the path traversed by the packet from its origin to the present ^ 
hop in terms of the MAC addresses of each hop visited by 
the packet. 

A router that receives the packet with ROC-6 accepts it 
based on the XLID, XADD tuple. The router then deter- 
mines if the packet has visited the router before and, if so, 
discards the packet. If no such loop is detected, the router 20 
then consults its routing table and obtains the LLID for the 
link to its next hop to the intended destination. Note that the 
address of the destination is specified in the payload of the 
packet, not in its header. Once the next hop and the LLID for 
the next hop are obtained, the router installs the mapping 25 
between the FL (incoming flow label) of the received packet 
and a new outgoing flow label and the LLID for the next hop 
towards the destination (obtained from its routing table). The 
router then substitutes FL with its outgoing flow label for the 
destination, adds its MAC address to the path-traversed field 30 
56, and sends the packet to the next hop. Thus, although such 
an approach is viable, the preferred approach to flow setup 
is source -routed flow setup, because it incurs much less 
communication and processing overhead. 

Thus, a scheme, for routing and switching in computer 
networks has been described. Although discussed with ref- 
erence to certain illustrated embodiments, however, the 
more general applicability of the following claims should 
not be limited thereby. 

What is claimed is: 

1. A method comprising: 40 
receiving a packet at a first router of a data network; 
forwarding the packet to a second router of the data 

network according to one of a plurality of forwarding 
modes specified by a routing operation code in the 
header of the packet, wherein the plurality of modes 45 
comprise (1) modes wherein the packet is accepted 
based on a receiving node address included in the 
header and (2) source switching, flow switching, and 
incremental modes wherein the packet is accepted 
based at least in part on a local link identifier included 50 
in the header. 

2. The method of claim 1, wherein the plurality of modes 
further comprise a broadcast mode wherein packets trans- 
mitted by the first router are accepted by all neighboring 
routers of the first router. 55 

3. The method of claim 1, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop -by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 60 

4. The method of claim 1, wherein a value of the routing 
operation code determines certain types of other information 
included in the header of the packet. 

5. The method of claim 4, wherein a sending node address 
is included in the header of the packet regardless of which 65 
of plurality of modes is specified by the routing operation 
code. 
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6. The method of claim 5, wherein the sending node 
address comprises a medium access code address of the 
sending node. 

7. The method of claim 4, wherein the receiving node 
address comprises a medium access code address of the 
receiving node. 

8. The method of claim 2, wherein the header of the 
packet includes a receiving node-assigned local link identi- 
fier if the routing operation code specifies one of the source 
switching or flow switching modes. 

9. The method of claim 1, wherein the header of the 
packet includes a flow label if the routing operation code 
specifies the flow switching mode. 

10. The method of claim 1, wherein the flow switching 
mode receiving routers are identified using local fink iden- 
tifiers associated with communication links between trans- 
mitting routers and intended receiving routers. 

11. The method of claim 1, wherein in the flow switching 
mode, flow states at routers of the data network are estab- 
lished according to information in data packets transmitted 
within the data network. 

12. The method of claim 11, wherein the information 
included in the data packets allows for bindings between 
incoming and outgoing flow labels to be established at each 
of the routers. 

13. The method of claim 1, wherein the header of the 
packet includes a source route to an intended destination if 
the routing operation code specifies the source switching 
mode. 

14. The method of claim 13, wherein the source route is 
specified in terms of local link identifiers used by routers in 
the data network. 

15. The method of claim 13 wherein the source route is 
obtained by using either a flood search process or a routing 
protocol operative within the data network. 

16. The method of claim 1, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the source switch- 
ing mode; 

reading in the header of the packet at the first router a 
source route; 

replacing a first transmitting router local link identifier in 
the header of the packet at the first router with a second 
transmitting router local link identifier needed by the 
second router. 

17. The method of claim 1, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the source switch- 
ing mode; 

reading in the header of the packet at the first router a 
source route; 

replacing a first transmitting router local link identifier 
and a first receiving router local link identifier in the 
header of the packet at the first router with a second 
transmitting router local link identifier and a second 
receiving router local link identifier needed by the 
second router. 

18. The method of claim 1, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the flow switching 
mode; 

reading in the header of the packet at the first router a 
source route; 
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replacing a first flow label in the header of the packet at 
the first router with a second flow label needed by the 
second router. 

19. The method of claim 1, wherein the packet comprises 
a data packet that includes flow setup instructions for a next 
receiving node. 

20. The method of claim 1, wherein the header of the 
packet includes a path-traversed field. 

21. The method of claim 3, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the label swapping 
mode; 

replacing a first flow label in the header of the packet at 
the first router with a second flow label by indexing a 
flow switching table stored at the first router. 

22. A packet for use in a data network, comprising: 
a header that includes a routing operation code that 

specifies one of a plurality of modes for forwarding the 
packet within the data network, wherein the plurality of 
modes comprise (1) modes wherein a packet is 
accepted based on a receiving node address included in 
the header and (2) source switching, flow switching, 
and incremental modes wherein a packet is accepted 
based at least in part on a local fink identifier included 
in the header and not on a receiving node address; and, 
a payload. 

23. The packet of claim 22, wherein the plurality of modes 
further comprise a broadcast mode, 

24. The packet of claim 22, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop-by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 

25. The packet of claim 22, wherein the header further 
includes a sending node address regardless of which oLthe 
plurality of modes is specified by the routing operation code. 

26. The packet of claim 25, wherein the sending node 
address comprises a medium access code address of the 
sending node. 

27. The packet of claim 22, wherein the receiving node 
address comprises a medium access code address of the 
receiving node. 

28. The packet of claim 22, wherein the header includes 
a transmitting node -assigned local link identifier if the 
routing operation code specifies one of the source switching, 
flow switching, or incremental modes. 

29. The packet of claim 22, wherein the header includes 
a receiving node — assigned local link identifier if the routing 
operation code specifies one of the source switching or flow 
switching modes. 

30. The packet of claim 22, wherein the header includes 
both a transmitting node- assigned local link identifier and a 
receiving node-assigned local fink identifier if the routing 
operation code specifies one of the source switching, flow 
switching, or incremented modes. 

31. The packet of claim 22, wherein the header includes 
a flow label if the routing operation code specifies the flow 
switching mode. 

32. The packet of claim 22, wherein the packet includes 
a source route to an intended destination if the routing 
operation code specifies the source switching mode. 

33. The packet of claim 22, wherein the header includes 
a path-traversed field. 

34. The packet of claim 33, wherein the path-traversed 
field comprises (1) a hop count specifying a total number of 
routers visited by the packet and (2) an ordered sequence of 65 
medium access control addresses of routers visited by the 
packet. 
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35. The packet of claim 22, wherein the header includes 
a payload-type field that specifies the type of payload that 
follows the header. 

36. The packet of claim 22, wherein the header includes 
a time to live field. 

37. The packet of claim 36, wherein the header further 
includes a version field that specifies a version of a protocol 
used to process the packet. 

38. The packet of claim 37, wherein the header further 
includes (1) a reliability field that specifies a degree of 
reliability with which the packet must be successfully for- 
warded by a router and (2) a priority field that specifies a 
priority that the packet should be assigned in a transmission 
queue of a router. 

39. The packet of claim 22, wherein the routing operation 
code determines which of a plurality of fields of information 
are included in the header of the packet, wherein the 
plurality of fields of information comprise (1) address infor- 
mation of a receiving router, (2) local link identifier infor- 
mation assigned by a transmitting router, (3) local fink 
identifier information assigned by a receiving router, (4) a 
flow label, (5) a source route, (6) a path traversed, and (7) 
a payload type. 

40. A router comprising: 

a neighbor identification table configured to allow the 
router to determine whether a received packet should 
be accepted and, if so, which of a plurality of switching 
tables to access to retrieve information for forwarding 
the packet within a data network; 

a source switching table of the plurality of switching 
tables, wherein the source switching table is configured 
to provide packet forwarding information which the 
router is to use to forward the packet using a source 
switching process; 

a flow switching table of the plurality of switching tables, 
wherein the flow switching table is configured to pro- 
vide packet forwarding information when the router is 
to forward the packet using a flow switching process, 
wherein the flow switching table specifies mappings 
from incoming flows to outgoing flows, local fink 
identifiers for next hops, and associated link-level 
information. 

41. The router of claim 40, wherein the neighbor identi- 
fication table is arranged so as to be indexed using local link 
identifiers assigned by neighboring routers to links commu- 
nicatively coupling the router thereto. 

42. The router of claim 40, wherein the neighbor identi- 
fication table is further arranged to provide pointers to the 
source switching table and the flow switching table. 

43. The router of claim 40, wherein the neighbor identi- 
fication table is arranged so as to be indexed using local link 
identifiers assigned by the router to links to neighboring 
routers. 

44. The router of claim 40, wherein the source switching 
table is arranged so as to be indexed according to local link 
identifiers assigned by neighboring routers to links commu- 
nicatively coupling the router thereto. 

45. A router of a data network, comprising: 
means for receiving a packet; and, 

means for forwarding the packet to another router of the 
data network according to one of a plurality of for- 
warding modes specified by a routing operation code in 
the header of the packet, wherein the plurality of modes 
comprise (1) modes wherein the packet is accepted 
based on a receiving node address included in the 
header and (2) source switching, flow switching, and 
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incremental modes wherein the packet is accepted 
based at least in part on a local link identifier included 
in the header. 

46. The router of claim 45, wherein the plurality of modes 
further comprise a broadcast mode. 

47. The router of claim 45, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop-by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 

48. The router of claim 45, wherein a value of the routing 
operation code determines certain types of other information 
included in the header of the packet. 

49. The router of claim 45, wherein the means for 
forwarding the packet comprise: 
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means for reading in the header of the packet a routing 
operation code that specifies the source switching 
mode; 

means for specifying an outgoing interface and link-level 
information for transmitting the packet to a next hop. 

50. The router of claim 45, wherein the means for 
forwarding the packet comprise: 

means for reading in the header of the packet a routing 
operation code the specifies the flow switching mode; 

means for mapping an incoming flow label to an outgoing 
io flow label; 

means for identifying a next hop; 

means for specifying necessary link-level information for 
transmitting the packet to the next hop. 

***** 



02/09/2004, EAST Version: 1.4.1 



